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PROGRESS IN PROJECT MANAGEMENT 


Work continues on new methodology for managing application 
system development projects. The goal being sought is a means to 
complete projects on schedule and on budget, and to have users 
satisfied with the resulting systems. While this goal does not seem 


unreasonable, particularly to user management, it can be a very 


difficult goal to achieve in some environments. In this report, we 
discuss user experience with two new methodologies aimed at 


achieving this goal. 


The City of Tacoma, Washington, with a popu- 
lation of 157,000, is one of the major cities of the 
Pacific Northwest. The city government is per- 
formed by an elected city council, supported by 
an appointed city manager (who administers the 
city departments) and an appointed public utili- 
ties board and a public utilities director (who 
administer city-owned utilities). These util- 
ities include electric power, water, and a small 
railroad. 

The City’s data processing department serves 
both the public utility departments and the city 
administrative departments, in a service bureau 
type of operation. The data processing depart- 
ment has an IBM 370/135 that operates under 
pos/vs. The system is scheduled 24 hours a day, 
five days a week. It serves 23 crT terminals and 
two remote job entry terminals. The City has a 
staff of 22 analysts and programmers. 

In 1975, data processing management was un- 
happy with the department’s system devel- 
opment performance. Good systems were being 
developed to meet user needs—but the projects 
were too often behind schedule and over cost. So 
management started to seek a better way to plan 
and control the system development process. 


In October 1975, a department representative 
attended a seminar given by J. Toellner & Associ- 
ates, of Los Angeles, California, on the company’s 
new SPECTRUM-1 project management system. 
SPECTRUM-1 looked like what the City was seek- 
ing. After an investigation of the system, per- 
mission to purchase the system was obtained in 
December 1975. SpecrruM-1 was installed in 
January 1976 and the first project was planned 
under it the following month. 

What has happened to their system devel- 
opment process in the intervening months has 
pleased both the data processing personnel and 
the user departments. We saw a project status 
board which displayed 21 projects controlled by 
SPECTRUM and 6 old projects not under SpEc- 
TRUM. The 21 projects under SPECTRUM were es- 
sentially on schedule and on budget. The 6 old 
projects, which had been so far along in devel- 
opment that they were not put under SPECTRUM, 
were not in as good a condition. All were behind 
schedule and two had significant cost overruns— 
up to several times the original budgets. While 
SPECTRUM-| has not eliminated all cost and time 
variances, it has greatly reduced them, say the 
people at the City of Tacoma. 
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What is SpeEcTRUM-I? It is a system devel- 
opment methodology for handling both large and 
small development projects, as well as enhance- 
ment and maintenance projects. The elements of 
SPECTRUM-1 include the following: (1) a method 
for getting top management direction and user 
department management involvement in data 
processing planning and control; (2) a structured 
approach to system development that involves 
three major phases divided into 13 sub-phases, 
plus defined quality review check points; (3) 15 to 
20 tasks per sub-phase, with defined methods to 
use and work products to be produced; and (4) es- 
timating guidelines for determining the resource 
requirements for each phase. These estimating 
guidelines take into account such factors as team 
size, team experience on this application, number 
of users, user availability, and so on. There is one 
manual for each of the 13 sub-phases. Each ana- 
lyst, programmer, project manager, and super- 
visor requires only a single book specially written 
for that person’s job function. Additional books of 
reference standards are available for staff use as 
needed. Documentation standards are provided 
for all project documentation. Separate manuals 
are available for the administration of software 
contracts and the control of purchased packages. 
For more information on SpecTrRuM-1, see Refer- 
ence lI. 

“Our first project under Specrrum-1 almost 
drove people up the wall,” said the Tacoma sys- 
tems and programming manager. “It forces a dis- 
cipline that is not always well received. But then 
there is a pleasant surprise when you find, at the 
end of a phase, that the work has in fact been 
completed, that there are no loose ends, and that 
schedule and budget are being met. An average 
user organization might be in awe of the apparent 
overhead of the methodology—but the results 
seem to justify that overhead.” 

The direction for the City of Tacoma’s whole 
data processing program is provided by a data 
processing advisory board. This board consists of 
the assistant city manager, the assistant director 
of public utilities, two department managers, and 
the data processing manager. The board meets at 
least once a month, to review project requests and 
project status. It is the approving agency for all 
projects. 

A screening function for project requests is 
performed by a data processing coordinating 
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committee. This committee consists of represent- 
atives from the departments. It reviews project 
proposals and assigns suggested priorities to those 
projects. 

On a small project, of up to one man-year in 
length, the project leader selects the appropriate 
tasks from an overall list of tasks. An initial esti- 
mate of times and costs is prepared at this time. 
By the end of the third sub-phase, much more ac- 
curate time and cost figures are developed. These 
more accurate figures are the basis for the “‘con- 
tract” price for the project which the user depart- 
ment must approve. At the end of the sixth sub- 


phase, which deals with the detailed design, an- 


other review of times and costs is performed. 

On a large project, the project leader may iden- 
tify some 250 tasks that will have to be per- 
formed. The initial estimate of times and costs is 
performed in much the same way as it is for small 
projects. But the City of Tacoma holds five re- 
views of the times and costs for the large projects, 
as opposed to three for small projects. 

Each task is described in considerable detail in 
the SpectruM-1 documentation. Several pages of 
narrative discussion tell what is to be done in the 
task. References are given to any detailed descrip- 
tions of how to perform a task, such as how to per- 
form interviews or how to do structured 
programming. A planning checklist is provided 
for each task, to help insure that all necessary 
things are done. Also, the work products to be 
produced by the task are defined, such as the 
forms that must be completed and the other docu- 
mentation that must be created. 

SPECTRUM-1| provides estimating guidelines for 
all tasks. Task worksheets list the different activi- 
ties that must be performed. For each activity, 
time standards are shown—for minimum, aver- 
age, and maximum complexity cases. The project 
leader selects the time standard he or she deems 
most appropriate for the activity. All of these 
times are then summed for a sub-phase, to give 
the first estimate of the man-hours required for 


that sub-phase. 


The next step in time estimating is to adjust this 
first estimate by means of environmental weight- 
ing factors. Eighteen weighting factors are con- 
sidered. These factors include team experience 
with the application area involved, user under- 
standing of the requirements, and so on. These 
factors are both additive and subtractive. For in- 


stance, for a team of one person, the team factor is 
-0.1, while for a team of three or more persons, 
the factor is + 0.2. The appropriate values are se- 
lected for the factors, the values are then added, 
and the total is used to multiply the first estimate 
of man-hours. The result is the estimated man- 
hours for the sub-phase. 

If the total hours for the project as a whole, or 
for one or more sub-phases, looks unacceptable, 
analysis is made to determine just what can be 
changed. Toellner (Reference 3) provides a dis- 
cussion of this time estimating procedure and 
the things to be cognizant of when using the 
procedure. 

The City of Tacoma found that the major diffi- 
culties they had with their previous methods in 
meeting time and cost estimates were due to over- 
looking things. Whole tasks might be overlooked, 
as well as environmental factors that affect how 
quickly tasks can be performed. Now, with the ex- 
tensive checklists provided by Specrrum-1, the 
City of Tacoma finds that these oversights are 
much less likely. There are still user-requested 
changes in the requirements in the middle of a 
project and these do affect schedule and budget. 
But the users recognize these are changes and that 
they will impact the times and costs. 

The City of Tacoma sometimes contracts for 
software to be developed by outside organiza- 
tions. The City now requests that SpEcrruM-1 be 
used for planning and controlling such projects 
and that SpeEcrruM-1 documentation be pro- 
duced. The outside suppliers sign non-disclosure 
agreements on the use of SpEcrRuM-1 and then 
use the system for developing and documenting 
the City’s application. 

So the City of Tacoma has found Specrrum-1 
to be most useful for managing their application 
system development projects. 


Airborne Freight Corporation 


Airborne Freight Corporation, with headquar- 
ters in Seattle, Washington, is the second largest 
air freight forwarder in the U.S. The company 
forwards air freight by using commercial air lines, 
air taxis, and commuter air lines. It has offices in 
77 locations in the U.S. and in 10 foreign loca- 
tions. Annual revenues are over $132 million and 
the company employs some 2,000 people. For its 
data processing, Airborne uses an IBM 370/148 
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batch system and a 370/145 on-line system tied to 
over 200 terminals. There is a development staff 
of 16 people for system development, mainte- 
nance, and production support. 

In 1975, a major consulting firm performed a 
study of Airborne’s data processing function. One 
of the recommendations made by the consultants 
was that Airborne install a project accounting and 
management system, as well as a system devel- 
opment methodology. These were in addition to a 
system standards and procedures manual cov- 
ering many other development and production 
functions. For the project accounting and man- 
agement system, Airborne considered both in- 
house development and purchasing a package. In 
October 1975, they chose PC/70, marketed by 
Atlantic Software, Inc. of Philadelphia, Pennsy]- 
vania. (We discussed PC/70 in our September 
1976 report.) 

Airborne initially chose to construct their own 
project management system, basing it on the ap- 
proach and methodology used by the consulting 
organization. After three man-months of effort, 
this approach was discontinued. Several project 
management packages were evaluated and in 
January 1976, SDM/70 was selected. It, too, is 
marketed by Atlantic Software. 

SDM/70 uses a phased approach to project im- 
plementation, with nine phases. The first three 
phases are concerned with determining require- 
ments, considering alternative solutions, and de- 
veloping the system specifications, in a language 
understandable by users. The next three phases 
are concerned with system design, program de- 
velopment, and testing. The final three phases 
deal with conversion, operation, and post-imple- 
mentation review. 

Six types of guidelines are provided. Methods 
guidelines deseribe in detail how each task is to be 
performed and give tutorial material where 
needed for understanding underlying concepts. 
Documentation guidelines tell how to prepare all 
documentation for each phase. Forms guidelines 
tell how to complete the required forms. Estimat- 
ing guidelines provide estimating parameters and 
tell how to estimate costs and schedules. Adminis- 
trative guidelines tell how to administer and con- 
trol project activities. Management guidelines 
describe the roles and responsibilities of user and 
executive managers during the development 
process. In addition, special guidelines are pro- 


vided for short duration projects and for on-going 
maintenance. 

SDM/70 also provides for user-oriented docu- 
mentation for the early phases of a project, when 
user involvement is so essential for identifying 
user needs and problems. Some of the other con- 
cepts upon which SDM/70 is based are the fol- 
lowing. Each task has a fully specified end 
product, checklists of pertinent design consid- 
erations, and pre-formatted forms with required 
information clearly indicated. Commitments in 
terms of both costs and schedules are limited to 
the next phase. Testing is also phased. And SDM/ 
70 provides a “release” approach for mainte- 
nance and enhancements. The guidelines also de- 
scribe the use of improved productivity 
techniques (HIPO, structured programming, etc.) 
that we discussed last month, as well as technical 
quality review, training of users, and operating 
steering committees. For more information on 
SDM/70, see Reference 2. 

After obtaining SDM/70, Airborne discarded 
the backlog of major projects that was then in ex- 
istence. They restructured all of these existing 
projects into about eight major projects and then 
performed a phase one study (requirements defi- 
nition) on the four most attractive projects. They 
then began work on the two most suitable proj- 
ects. 

Airborne now divides their project portfolio as 
follows. When a user department submits a 
request for service, the request is reviewed by a 
systems department manager. If the request 
clearly involves less than five man-days of time 
and is considered worthy, it is immediately re- 
ferred to the production support function. The 
work is done without the use of SDM/70 methods 
but is documented according to SDM/70 stand- 
ards. 

If the work will involve over five man-days of 
time, the service request is given to a methods 
analyst. The analyst can spend up to four hours in 
investigating the request. The analyst talks to 
both users and technical people, and develops a 
concise statement of the problem, the possible 
benefits to be realized, and the size and scope of 
the project. If the project is less than two man- 
months in size, the vice president, systems, can as- 
sign the priority. Larger projects are referred to 
the company’s steering committee. 

The steering committee consists of the three 
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top vice presidents; also, the vice president, sys- 
tems, and the systems manager attend all the 
meetings. The committee meets monthly to re- 
view project progress and assign priorities for 
new projects. On a quarterly basis, the committee 
reviews the allocation of all development re- 
sources. 

For each development project, Airborne sets 
up a user review group, consisting of upper man- 
agement or staff of the affected user departments. 
These groups meet during the projects, particu- 
larly at the end of the phases, to review the docu- 
mentation that has been produced and to 
compare progress against plan. 

After more than one year of use of SDM/70, 
Airborne has found the following benefits. The 
phased approach has been of great help in com- 
municating with user department management 
and the steering committee. It has also helped to 
establish credibility in the eyes of both top man- 
agement and user department management. User 
management no longer expects end-to-end cost 
commitments, and recognizes that the early esti- 
mates will later be refined into commitments. 
SDM/70 provides for the uniform tasking of proj- 
ects while still allowing a good amount of flex- 
ibility in project conduct. The methodology 
forces the planning of a project, which helps to 
prevent false starts and implementing the first so- 
lution that comes to mind. And the documenta- 
tion gives uniform, comprehensive results and 
provides effective communication with users and 
top management and between systems groups. 


Managing system development 


System development is a complicated function. 
It is much more complex than it might first ap- 
pear to be. One of the reasons for this deceptive 
simplicity is that, with manual systems, the 


people involved with the system take corrective 


actions in order to make the systems work. To a 
certain extent, manual systems are self-correct- 
ing. So the system building process might appear 
to be simpler than it really is. 

To illustrate the breadth and depth of the sub- 
ject, here are some of the aspects involved in man- 
aging system development. (The dates in 
parentheses indicate our previous reports in 
which we discussed these subjects.) 


TABLE 1 
MANAGING SYSTEM DEVELOPMENT 


Senior management guidance and control 
Use of steering committees (May 1975) 
Long range plans for data processing (August 1975) 
Formal project initiation and funding (August 1975) 
Sub-divide large projects into small ones (October 1970) 
Management reviews with “creeping commitment” 
(May 1973) 

Project management 
Phased approach to project development (May 1973) 
Comprehensive task checklist 
Time and resource estimating procedure 
Defined work products for each task (May 1973) 
Schedule preparation procedure (September 1976) 
Project progress control systems (September 1976) 

Design and construction 
Requirements determination methods (July 1977) 
Methods for handling complexity (July 1977) 
Installation performance standards (August 1975) 
Quality review procedures (July 1977) 

Staff development 
Career paths for staff members (August 1971, July 1975) 
Training programs (August 1972) 


Why all of this complexity? There are lots of 
things that have been and are being developed in 
the world that do not seem to involve this variety 
of considerations. Why are information systems 
different? 

Our position is that information systems really 
are not so different. Consider, for instance, the 
following two situations of building a house. 

Situation one. A single house is built on a site 
isolated from other houses. It is built by a very ex- 
perienced craftsman. This craftsman has built 
many similar houses before. He is able to lay the 
foundation, do the rough and finish carpentry, the 
plumbing, the electrical work, the painting, and 
so on. The customer may have to give this crafts- 
man only a rough sketch of what is desired, plus 
some constraints such as a target maximum cost 
figure, in order to get a satisfactory house. Fur- 
ther, this method can work for houses ranging 
from very modest to quite outstanding in quality. 

Situation two. Many houses are being built in 
an urban area. The houses are being built by a 
large labor force, consisting of specialists in a 
wide range of skills. One group of people lay the 
foundations, another group does the rough car- 
pentry, still another group does the plumbing, 
and so on. But in addition, generations of expe- 
rience with this type of construction has shown 
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that other things must be considered. The urban 
area needs zoning laws, so that the new houses are 
compatible with existing construction. The urban 
government must-have a process of requiring de- 
tailed drawings and specifications on the houses, 
plus a set of building codes (standards). The draw- 
ings and specifications must be checked and ap- 
proved and building permits issued before 
construction can start. Further, these drawings 
and specifications must be prepared in a manner 
to be useful by the different building skill groups 
involved. The urban government must also per- 
form an inspection process during: construction, 
to make sure that the construction codes are 
being met. Finally, the houses must be built ac- 
cording to the plans; any changes made during 
construction can result in delays and extra costs. 

As a matter of fact, experience with construc- 
tion has shown that even more “overhead” is re- 
quired. When the remodelling of a house is 
contemplated, again the plans must be prepared 
and approved before the work can start—to make 
sure that construction codes are followed. And 
even with maintenance, some types of mainte- 
nance work must be done by state-licensed crafts- 
men, as in the case of electrical work. 

Our point is that the construction of a tract of 
houses in an urban area has many of the aspects of 
complexity as does the building of multiple, in- 
tegrated application systems in a multi-program- 
ming environment. 

It is when one moves away from the individual, 
stand-alone system built by one or more very 
skilled craftsmen that the true complexity of the 
process becomes apparent. The “overhead”’ 
needed to properly manage this complexity be- 
gins to stand out when numerous, inter-related 
systems are being built by “average” craftsmen. 

In our May 1973 report, we discussed user ex- 
periences with a methodology developed by 
Touche Ross & Co., embodying a phased ap- 
proach to system development. And in our De- 
cember 1974 issue, we discussed some user 
experiences with PripgE, a widely used packaged 
methodology for system development. In the in- 
terim, two other methodologies—SpecTRuM-1 
and SDM/70—have reached the marketplace 
which incorporate somewhat different points of 
view. We are thus returning to this subject area in 
order to give a somewhat broader perspective of 
it. We believe that this is an area in which 


data processing management will continue to be 
interested. 

A comment on terminology. In our September 
1976 report, we discussed “project management 
systems’ for project planning and control. These 
were mechanized systems for helping to plan the 
allocation and scheduling of development staff 
members and for keeping track of actual work 
versus plan. While the term “project manage- 
ment systems’’ is widely applied to such systems, 
perhaps the term “project control systems” or 
even “project planning and control systems”’ 
would be more appropriate. These project con- 
trol systems represent only a small portion of the 
overall project management subject area. 

We talked to numerous people about project 
management systems, in the preparation of this 
report. We would particularly like to acknowl- 
edge the contributions of John Toellner, whose 
company developed Specrrum-1, of David Katch 
who developed SDM/70, and of Michael Mul- 
cahy, Director of Data Processing for the Munici- 
pality of Metropolitan Seattle, Washington, plus, 
of course, the people at the City of Tacoma and 
Airborne Freight. 


What is wrong with older methods? 

A still-all-too-familiar problem is the case 
where an organization’s application system de- 
velopment projects are behind schedule, over 
cost, and end up not really satisfying the users. 
The data processing field is making progress 


toward solving this problem, but difficulties still _ 


exist. 

What are some of the shortcomings with 
today’s “conventional” methods of system devel- 
opment? First, there is usually a voluminous flow 
of requests for service from user departments into 
data processing departments, asking for new sys- 
tems, enhancements to existing systems, and 
maintenance on existing systems. These requests 
are so voluminous that the data processing staff is 
kept constantly under pressure. Much of the time 
of the development staff is spent on the mainte- 
nance and small enhancement projects, to the 
point where it is hard to find time to do larger, 
more meaningful projects. Many of these mainte- 
nance and enhancement requests are due to the 
fact that the application systems were not devel- 
oped properly in the first place. 


Perhaps even worse, when the larger, more 
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meaningful projects are undertaken, the man- 
hour requirements are seriously under-estimated. 
Tasks are overlooked, programmers jump into 
programming before design is completed, false 
starts occur and rework must be done, time esti- 
mates are made on the basis that the best people 
will be doing all of the work, and so on. The natu- 
ral result is that projects fall behind schedule and 
go over budget. As such a situation develops, 
there is a bad psychological effect on the team 
working on the project. The team sees that the 
time and cost estimates are unrealistic and that 
those estimates cannot possibly be met. The team 
members feel that they have been put in an unte- 
nable position and get depressed. 

One person that we talked to gave the follow- 
ing reasons for time and cost overruns on projects. 
About 70% of the time, he said, the cause for the 
time and cost overrun was just poor estimating in 
the first place. In another 10% of the cases, the 
cause was changes in the requirements requested 
by the users. Another 10% of the time, the devel- 
opment staff members were not as productive as 
expected. And the final 10% of the time, data 
processing management was at fault. Of course, 
for any given project, the troubles can be caused 
by two or more of these reasons. 

If poor estimating is the main cause of the trou- 
bles, it is probably due to two main reasons. For 
one thing, whole tasks or activities can be com- 
pletely overlooked. The other main reason is that 
the environment in which the work is to be done 
is not fully considered. Yes, it may be realized that 
new, inexperienced staff members may have to be 
used on a project. But it may not be fully appre- 
ciated that a large team size will slow down the 
work of each team member, or that the knowl- 
edgeable people in the user departments will not 
always be available when needed. And it may be 
overlooked that the team members will be inter- 
rupted in order to perform “fire fighting’ mainte- 
nance work on other systems. 

Another person we contacted gave his ideas on 
overruns. One reason is using poor estimating 
techniques and not adjusting the estimates at key 
milestones when the work is better defined. An- 
other is the lack of an effective freeze process 
which helps keep a project from ballooning. A 
third reason is the mixing of development and 
maintenance work, where maintenance keeps 
taking time away from development. 


These are only a few of the shortcomings of the 
older, “conventional” system development meth- 
ods. None of these shortcomings is particularly 
difficult to understand. The problem is that there 
are so many shortcomings. And they tend to be 
overlooked unless a systematic means is used to 
consider each one and ask, “is this a potential 
problem on this project?” The upshot is, then, 
that better methods are needed for developing 
application systems. 


Today’s project management systems 


Today’s project management systems (PMs) at- 
tack the above problems on several fronts. Some 
of the principles that these systems use are the 
following. 

Doing the right things. Top management guid- 
ance of the whole data processing program is an 
essential part of the new pms. The vehicle most 
commonly used for obtaining this participation is 
the steering committee, consisting of members of 
executive management. The methodologies make 
such a strong point of the need for this participa- 
tion that top management finds it hard to refuse. 
Further, the methodologies describe the means 
by which these steering committees can perform 
effectively. 

Doing things right. The modern methodologies 
stress the need for carefully determining user re- 
quirements, so that the problem is properly iden- 
tified and defined. They urge that a variety of 
alternative solutions to the problem be consid- 
ered, not all of which need involve the computer. 
If the best solution is selected and carefully imple- 
mented, then the need for subsequent enhance- 
ments and maintenance is greatly reduced. 
Further, the methodologies provide good docu- 
mentation—for users, for computer operations, 
and for any subsequent enhancement and mainte- 
nance needs. 

Establishing credibility. By providing a mecha- 
nism for making more accurate time and cost esti- 
mates, the new methodologies tend to build up 
the credibility of the data processing depart- 
ment’s promises. Credibility comes from doing 
what was promised—meeting schedules, keeping 
costs under control, and producing an efficient 
system that meets user needs. 

To give a more comprehensive picture of these 
new methodologies, here is a list of the character- 
istics of today’s project management systems. 
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Note, however, that not all characteristics need 
apply to any one pms. Each system seems to have 
its strong and its weaker points. 


TABLE 2 
CHARACTERISTICS OF PMS 


Overall direction and administration 
Senior management guidance 
Long range planning for data processing 
Careful determination of user requirements 
Resource usage planning and control 
Phase-limited commitment 
Post-implementation reviews 
Phased approach 
Defined phases (and perhaps sub-phases) 
Defined tasks for each phase 
Defined work products for each task 
Phased testing 
Detailed guidelines and checklists 
For: 
Methods 
Documentation and forms 
Time and cost estimates 
Maintenance, small projects, enhancements 
Design and construction methods 
General description of how to perform each task 
Brief description of applicable technology 
Management of the data resource 
Control methods 
Quality and progress review points, at phase ends 
Approval to continue only through next phase 
Tie-in with project control systems 
Control of changes to design, after freeze points 
Administration of software contracts 
Training and consulting assistance 
Rewrite of manuals to fit company’s standards 
Retention of desired forms, procedures, standards 
Assistance in setting initial project priorities 
Post-implementation review of the PMS itself 
How to use the methodology, conduct interviews 
How to capture user requirements 


As we said, not all of the new pms have all of 
the above characteristics. But the list gives 
reasonable idea of the features of these new 
methodologies. 


How do PMS control system development? 


The new project management systems seek to 
get system builders to do the right things, then to 
do those things right, and thereby to build up 
credibility. 

Users tend to want to get their new systems, en- 
hancements, and changes onto the computer just 
as fast as possible. The new methodologies help to 
make sure that the problem is identified and de- 


fined correctly and that the best of several al- 
ternative solutions has been selected. These steps 
may seem to slow down the projects, in the eyes of 
users, but they make ultimate satisfaction much 
more likely. 

By providing extensive checklists, which apply 
to a large variety of types and sizes of projects, the 
new project management systems make it less 
likely that tasks will be overlooked. 

The new pms provide detailed task definitions, 
including the work to be done and the documen- 
tation to be produced. Standard forms provide 
consistency and make sure that all necessary tasks 
have been considered and performed. 

Time estimating guidelines may be provided, 
to help insure that all relevant factors are consid- 
ered when the estimates are prepared. 

Quality and progress review checkpoints, at 
the end of each phase, help insure that each phase 
has been performed completely and correctly. In 
theory, work does not commence on the next 
phase until the previous phase has passed its 
checkpoint. In practice, if everything seems to be 
going well, project management often will take a 
gamble and start work on the next phase before 
the previous checkpoint has been passed. How- 
ever, project management recognizes that this is a 
gamble, and generally tries to get the review per- 
formed as soon as possible. 

Finally, the new pms impose a control over all 
changes after preliminary design has been accom- 
plished. This principle applies at both the system 
level and at the program level. Formal change 
control helps insure that new ideas cannot be 
“sneaked in’”’ to the system plans. And the meth- 
odology requires that any change which is consid- 
ered be properly analyzed before it is 
incorporated and properly documented after it is 
in. 

These, then, are some of the ways in which the 
new PMs control system development so as to 
greatly reduce problems that have plagued the 
earlier methods. 


Is all this overhead necessary? 


The use of a modern pms appears to involve a 
lot of overhead. “Ts all of this overhead really nec- 
essary?’ you might ask. “Our users get edgy if too 
much time is taken up with planning a project, in- 
stead of getting on with the job. Do we have to 
use all of the formality of these pms?” 
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The answer seems to be, as is so often the case, 
both Yes and No. Let us consider the No side of 
the answer first. If you are building mostly inde- 
pendent, stand-alone systems with highly skilled 
people, and if there are just some aspects of your 
system development process that you are un- 
happy with, then you may not need the formality 
of a full pms. You could study the characteristics 
of a full pms and select just those features de- 
signed to give the improvements you seek. (This 
point is controversial, as we will discuss shortly.) 

The Yes answer applies to those situations 
where a number of inter-related application sys- 
tems are being built and used, a data base may 
also be in use, and there is a mixture of novice, 
junior, and experienced staff members. In such sit- 
uations, the likelihood is very great that the for- 
mality of a full pMs is needed. 

Of course, there is a wide range of situations be- 
tween these two extremes. Our opinion is, though, 
that a good fraction of the computer-using organ- 
izations would benefit from the use of a full pms. 
For instance, we have seen cases where an on-line 
time sharing service could well have used the 
small-project version of a full pms for developing 
a stand-alone application system for a small busi- 
ness. We have seen other cases where an inde- 
pendent software firm could have used a pms to 
advantage for develpoing a set of applications for 
a small business. All in all, we believe that the an- 
swer * Yes, the overhead of a full pms is necessary”’ 
is true more often than it is not. 

“Well, how about this top management in- 
volvement?” you might ask. “Top management 
has many demands on its time—and after all, the 
data processing budget only represents one or 
two percent of the organization's total budget. 
How can top management’s attention be justified 
under these circumstances?” 

A reasonable answer is that data processing is 
muchilike the central nervous system of the hu- 
man body. It carries much of the information on 
which the organization depends. The central ner- 
vous system may represent only a small percent- 
age of the total weight of the human body. But its 
importance far exceeds its relative weight. 

In short, if application systems are not devel- 
oped properly, at the very least substantial re- 
sources may be wasted. But even worse, the 
systems that are poorly developed may not serve 
the user departments well. And this in turn can 


affect the efficient performance of those user de- 
partments. Since the effects of good or poor sys- 
tem development are so wide reaching, top 
management can afford to spend some reasonable 
amount of time in the guidance and top level con- 
trol of this function. 

Just how much overhead is involved in the use 
of a full pms? We tried to find out. It is difficult 
information to obtain. Perhaps 10% of the total 
man-hours in a project might be spent in pMs- 
type activities. Not all of this is extra time, of 
course. For instance, some documentation would 
have to be developed anyway. Then, too, when 
the elimination of false starts and rework are con- 
sidered, it is quite possible that a pms-controlled 
project uses less time and that future maintenance 
and enhancement times are also reduced. 


What are the options? 


But the question remains, does a user organiza- 
tion have to take all or nothing of a full pms? The 
answer seems to be No. The formality of a full pms 
might be desirable for most computer-using or- 
ganizations, but there are still some options open. 
Let us consider what some of those options are. 

“Voluntary” versus “mandatory” use. Some or- 
ganizations that we have talked to have decided 
not to impose the pms as a mandatory standard. 
Instead, they leave it up to each project leader to 
decide how much or how little of the pms will be 
used on a given project. They hope that in time, 
the pms will be accepted for all projects. Other 
organizations, however, have decided that the 
only way they are going to get their system devel- 
opment under control quickly is to impose the 
PMS as a mandatory standard on all projects. This 
is one option open to users. 

“Enhance present system’ versus “install new 
methodology.” The user organization may al- 
ready have an extensive set of installation stand- 
ards that it does not wish to replace. In such a 
case, it may only seek to select certain parts of a 
full pms and then modify those to fit in with its 
standards. At the other extreme are those organi- 
zations that feel their present methods are quite 
inadequate and would prefer to replace them 
with the new methodologies. 

If the decision is made to enhance the present 
installation standards, then there is a series of op- 
tions available as to which enhancements to 
make. These options include the following: (1) 
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which phases of the pms to adopt, (2) the number 
of standard tasks to prescribe for each phase, (3) 
the number of defined work products to be pro- 
duced by each task, (4) how each task is to be per- 
formed, and (5) the degree of detail used in 
making the man-day time estimates for each 
phase. 

One representative of a consulting firm that we 
talked to said that his firm advocated this “en- 
hancement” approach. His firm had developed an 
almost complete pms methodology. On con- 
sulting assignments, the firm’s consultants would 
recommend that the client install only those 
standards that were missing from the client’s set 
of installation standards, and that were consid- 
ered desirable. This consultant claimed that the 
enhancement approach made it easier for users to 
get the benefits of a PMs, as opposed to installing a 
complete, new PMS. 

There are, of course, counter arguments to this 
approach. One such argument is that the ap- 
proach leads to fragmented solutions to specific 
problems, rather than to integrated solutions. An- 
other argument is that when these fragmented so- 
lutions are developed, it is then quite difficult to 
develop an integrated solution. 


“Full pms” versus “abbreviated version.” Even 
users of a full pMs may have the option of using an 
abbreviated version for smaller projects. One 
might argue that the abbreviated version could be 
used on the larger projects, too, in order to avoid 
some of the overhead of the full pms. We did not 
encounter anyone who advocated this approach, 
but it is a possibility. 

Another option is whether or not a project 
planning and control] system is to be used in con- 
junction with the pms. We discussed project plan- 
ning and control systems in our September 1976 
report. Given a task list and the resources re- 
quired to accomplish the tasks (which could come 
from the pms), the pp&c system can help plan and 
schedule the project, and can provide periodic 
progress reports showing actual progress versus 
plan. 

It seems to us that if data processing manage- 
ment is reasonably well satisfied with the present 
application system development process that is 
used, then “enhancement” could be selected in- 
stead of installing completely new methodology. 
But if data processing management and/or user 
department management are reasonably dis- 


catisfied with the present methods, then the in- 
stallation of a full pms should be considered. 


Installing a PMS 


As we have pointed out in numerous past issues, 
many software products should be considered as 
tools, not solutions. That is, if the computer-using 
organization is in a “crisis” situation, the software 
package will probably not cure the crisis and 
may, in fact, only make it worse. It seems to us 
that a full pms of the type we have been dis- 
cussing, on the other hand, comes much closer to 
being a solution. The installation of a full pms 
might alleviate many of the problems in a crisis 
situation for system development. 

There are a number of problems associated 
with the installation of a full pms, however. One 
organization that we talked to said that the user 
ought to allow about one full year for getting the 
system in and under proper use. Others agreed 
that there were problems in installing a pms but 
felt that one year was a longer period than they 
required to get the methodology in full operation. 
In fact, significant parts of a pms can be installed 
in from one to two months. 

Following are some of the problems that are in- 
volved in installing a pms. The pms manuals may 
have to be modified so as to be compatible with 
the company’s existing systems and procedures. 
Company-standard names and terminology, as 
well as certain installation standards and oper- 
ating methods, which are just as good as those 
used in the pms, should be retained. The rewriting 
of the manuals to incorporate such changes can 
either be done by the supplier (at extra cost) or by 
the company. This is a substantial activity. 

Another problem has to do with setting up the 
manuals of the methodology so that they are suit- 
able for use by the existing and near-future staff. 
Novice system analysts, for instance, will desire a 
good deal of narrative discussion of each task that 
they are to perform. Experienced system analysts, 
who understand the tasks but who are just becom- 
ing acquainted with the pms, may want guidelines 
but not extensive narrative. And experienced sys- 
tem analysts who have used the pms often may 
just want checklists. If the pms has not been set up 
to meet such needs in the first place, then such re- 
quired changes will involve a non-trivial task. 

The first project that is planned under a full pms 
may cause shock waves to go through the data 
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processing staff and the affected user depart- 
ments. The amount of the planning activities may 
seem excessive. And the man-days that are esti- 
mated to be required may seem unreasonable. 
Users may be suspicious that the new methodol- 
ogy just pads the times and costs, and may feel 
that the whole project should move faster. Expe- 
rience will show whether or not the pms activities 
and estimates are reasonable and realistic. 

Most pms use a phase limited commitment phi- 
losophy. This philosophy requires that each phase 
be completed, reviewed, and its work products 
approved before work begins on the next phase. 
As we indicated earlier in this report, in practice 
the “creeping commitment” philosophy is not 
followed exactly. If the previous phase has gone 
reasonably well and the project is close to sched- 
ule and budget, the project leader may start work 
going on the next phase before the previous phase 
is reviewed. The reason, of course, is to keep the 
project team members busy. But it should be rec- 
ognized that this action is a gamble on the part of 
the project leader. 

It was emphasized to us by one user that a pms 
never replaces a good analyst. But a pms does help 
a good junior analyst perform like an experienced 
analyst. It compensates somewhat for a lack of ex- 
perience. It does not, however, make a good ana- 
lyst out of an average one. 

Some of today’s pms prescribe just how each 
task should be performed. Others provide a good 
deal of flexibility on task conduct. For instance, 
for program design and construction, some PMS 
may prescribe a “standard” method to be used for 
all programs. In contrast, others allow the pro- 
grammers to choose among several methodol- 
ogies, such as modular programming, structured 
programming, Warnier’s method, and so on. Data 
processing management would have to decide 
just how much flexibility is desired in the use of 
the PMs. 


Conclusion 


As we indicated in Table 1 above, the subject of 
managing system development is a complex one. 
We have treated various aspects of the subject in 
numerous previous issues. Because the subject 
continues to challenge data processing manage- 
ment, we expect to return to some of the aspects 
of it in future issues. 
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As opposed to some software systems—such as 
data base management systems and project plan- 
ning and control systems—which should be con- 
sidered tools more than solutions, we think that 
project management systems can be viewed as so- 
lutions. Thus a data base management system 
should be installed only after an organization has 
its data pretty well under control; it should not be 
installed to get that data under control. A project 
management system, however, can be installed in 
order to get the system development process un- 
der control. 

In Table 2, we gave the main characteristics of 
today’s pms. As we pointed out, not all pms have 
all of these characteristics, but the table can be 
useful in helping to judge the scope of any par- 
ticular pms. 


With full project management systems, we be- 
lieve that the computer field is making real prog- 
ress toward the goal of getting application 
systems done on time, within budget, and of satis- 
faction to the users. 
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One of the major computer field trends during the 1970s has been toward the 
use of the shared-data base that serves multiple applications. Numerous bene- 
fits are being obtained from data bases—but at the same time, they have 
brought into much sharper focus the need for assigned responsibility and 
control of the organization's data resources. The data administrator function 
is being set up and given this responsibility. And data dictionaries are being 
installed as tolls for the data administrators. Next month, we will describe 
some user experiences in “installing a data dictionary.” 
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